-
Notifications
You must be signed in to change notification settings - Fork 12.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Formatting and consistency changes #1112
Conversation
Move to a more sensible and readable multi-line CSS format. Better for diffs too.
Four spaces is generally the most common indentation level, and particularly common for CSS. Capitalized the DOCTYPE both to avoid issues being created about it, and to adhere to a more common pattern. Added closing tags to the 404 for the same reasons.
Make the file readable.
👍 to everything but not capitalize DOCTYPE. PLZ PLZ PLZ |
+1 to everything but -Infinity for capitalized doctype. |
👍 |
LGTM. Some of these decisions do not match my personal coding style (tabs instead of spaces? FFFFUUUUU), but I’ll happily ignore that fact for the sake of project consistency. |
One thing that’s probably a mistake though — what’s with the double newlines at EOF? Seems like one is more than enough, no? |
👍 Readable code; a measure of the developers skill. One question though: What are the arguments that I should be using 4 spaces in stead of 2, besides personal coding-style preference? I prefer to keep my CSS within the 80 columns. Any remote terminal I connect to, to apply some patch in VIM, remains properly usable. (Of course this is not always feasible) When using a CSS preprocessor, indenting each nested set with 4 spaces increases the column count tremendously. |
He said "tabs instead of spaces" not "4 vs 2 spaces". However I could be misinterpreting what he meant. |
Where are the double newlines at? Related info for the curious: http://stackoverflow.com/q/729692/96656
None of which I know. 4 spaces appears to be the most common convention across various languages (pretty sure I saw a FE survey a few years ago that showed 4 to be the most commonly used too). It's pretty readable.
You shouldn't really be nesting to that extreme. 1 or 2 level nesting max :) |
The blank line at the end of all files is not necessary (and perhaps considered untidy). It's not the same thing as "files should end with a new line" - which is editor-config, not user, dependent. This https://github.com/h5bp/html5-boilerplate/pull/1112/files#L0L42 did not end with a new line previously - the git-diff-comment is referring to the previous line. All files in this commit end with a blank line - which is itself terminated with a newline char. In pseudo-detail Bad (typical with textmate IME)
Good/expected
This commit
|
Thanks for the explanation! Was wondering why I didn't get the newline warning all the time - Vim obviously gets it right whereas files from other editors sometimes don't. I'll correct this. |
Cleaned up and applied to master in 7a2f9dc Thanks |
Up for review.
Steps toward reducing the number of repeat issues we get around many of these things and improve diff/cat readability.
Also aiming to work towards ensuring that HTML5 Boilerplate can continue to be used with "no surprises" by web app/site developers and more specialized web app boilerplates/toolkits. I think the future of the project is as much to provide a starting point for web app boilerplate/toolkit developers as it is to be a resource for beginners to learn from. In keeping with that, I'm open to any adaptation of the project that can help make it even more useful for those developers.
Thanks.